A virtual machine is an abstraction—a “virtualization”—of an actual physical computer system. FIGS. 1A and 1B show two possible arrangements of virtualization software in a computer system 70 that implements virtualization. A virtual machine (VM) 20 or “guest” is installed on a “host platform,” or simply “host,” which will include system hardware 10 and virtualization software 80, which comprises one or more layers or co-resident components including system-level software, such as an operating system or similar kernel, or a virtual machine monitor or hypervisor as described in more detail below, or some combination of these. The system hardware typically includes one or more processors 11, memory 13, some form of mass storage 14, and various other devices 17.
In the conceptualization of virtual machines shown in FIGS. 1A and 1B, each VM 20 includes both virtual system hardware 28 and guest system software 29. The virtual system hardware typically includes at least one virtual CPU 21, virtual memory 23, at least one virtual disk 24, and one or more other virtual devices 27. It should be understood that the various virtualized hardware components of virtual system hardware 28 are merely conceptual representations of an execution environment for the guest operating system and applications. As suggested by the dashed box indicating the virtual system hardware 28, components of virtual system hardware 28 do not exist as physical or software entities, but instead are actually implemented by virtualization software 80 using known techniques to emulate the corresponding physical components. While the components of virtual system hardware 28 are implemented by virtualization software 80, the state of these components forms part of the state of VM 20, and are therefore represented within VM 20. Guest system software 29 includes a guest operating system (OS) 22 and drivers 25 as needed for the various virtual devices.
A single VM may be configured with one or more than one virtualized processor. Symmetric multi-processor (SMP) systems can be virtualized so that each VM can access the resources of multiple virtual processors, which may be mapped to one (using time-slicing) or more than one physical processor of the host platform. In this manner, each guest VM executes on system hardware 10 and physical CPU(s) 11 in its own “context,” which is provided by virtualization software 80. A “context” generally includes the state of all virtual address space, as well as the set of registers (including privilege registers), with all hardware exception and entry points. Thus, although they share system resources, each guest VM is isolated from one another and from the virtualization software. Applications 26 running on each VM may function substantially as they would if run directly on a physical computer, even though the applications are running at least partially indirectly. Executable files may be accessed by guest OS 22 from the virtual disk 24 or virtual memory 23, which are mapped to portions of the actual physical disk 14 or memory 13, respectively, which portions are allocated to that VM by virtualization software 80. The design and operation of virtual machines are well known in the field of computer science.
Virtualization software 80, also referred to herein as “virtualization software layer,” or “virtualization layer,” may include one or more software components and/or layers, possibly including one or more of the software components known in the field of virtual machine technology as “virtual machine monitors” (VMMs), “host operating systems,” or virtualization “kernels.” As used herein, the term, “virtualization software” refers generally to software that enables virtualization in a virtual computer system. Virtualization software 80 is generally located logically between all virtual machines and the underlying hardware platform and/or system-level host software. FIGS. 1A and 1B show one or more virtual machine monitors that appear as separate entities from other components of the hypervisor and perform functions as described in more detail below. Those skilled in the art may recognize that such a representation of these components is provided only for the sake of simplicity and clarity and by way of illustration. The distinctions between and among the various components of a virtualization system are not always so clear-cut, and the use of the term “virtual machine monitor” or just “VMM” is meant to encompass the component(s) in the virtualization software that perform the indicated functions, regardless of what name they are given.
Computer system 70 may be fully virtualized or para-virtualized. As the term implies, a “para-virtualized” system is configured in some way to provide certain features that facilitate virtualization. For example, guest operating system 22 may be designed to avoid hard-to-virtualize operations and configurations. For example, the guest operating system may be written so that it avoids certain privileged instructions, certain memory address ranges, etc. As another example, a para-virtualized system may include an interface within the guest that enables explicit calls to other components of the virtualization software. The phrase “degree of virtualization” refers generally to the extent to which the guest operating system is specialized to support virtualization.
FIG. 1A shows a “non-hosted” configuration, whereas FIG. 1B shows a “hosted” configuration. The non-hosted configuration illustrated in FIG. 1A deploys one or more VMMs 30-30n on top virtualization kernel 60. Kernel 60 is constructed specifically to provide efficient support for VMMs 30-30n. In particular, kernel 60 includes device drivers to manage and control physical system hardware 10, and to assign and distribute resources to VMMs 30-30n. A console operating system 42 and associated applications 43 may be provided to e.g., as a boot-loader for kernel 60, to provide a user interface to allow a user (e.g., an administrator) control over the operation of kernel 60, and/or to interact with applications executing on each of the virtual machines. Of course, administrative functions of kernel 60 and VMs 20 may be accessed remotely via a network.
In the hosted configuration shown in FIG. 1B, VMMs 30-30n run directly on the hardware platform along with host operating system 50. In a hosted virtualized computer system, an existing, general-purpose operating system forms “host” operating system 50 that is used to perform certain input/output (I/O) operations, alongside and sometimes at the request of a VMM. In this configuration, host operating system 50 includes driver 58 and one or more executable applications 56 that serve a number of virtualization functions, including provide an data interface between VMMs 30-30n and physical devices, manage and distribute system resources, and provide user interfaces to virtualization system and the inputs and outputs to each of the virtual machines. Host operating system 50, installed drivers 54, VM applications 56, along with other user applications 43 form host system software 52. The Workstation product of VM ware, Inc., of Palo Alto, Calif., is an example of a hosted, virtualized computer system, which is also explained in U.S. Pat. No. 6,496,847 (Bugnion, et al., entitled “System and Method for Virtualizing Computer Systems”). Thus, the term “host” in this particular context refers to the host operating system that is used to support a virtual machine, whereas, generally speaking, it refers to the physical host platform on which the virtual machine resides.
With respect to terminology, it should be noted that kernel 60 shown in the non-hosted system in FIG. 1A is not the same as the operating system kernel within the guest operating system 22. As is well known, every operating system has its own kernel. Note also that kernel 60 is part of the “host” platform of the VM/VMM as defined above even though the configuration shown in FIG. 1A is commonly termed “non-hosted.” Kernel 60 may be considered to be both part of the host platform and part of the virtualization software. The difference in terminology is one of perspective and definitions that are still evolving in the art of virtualization.
A virtual machine environment provides a convenient platform for efficient logging and replay of execution. Logging and replaying the execution of a virtual machine has several applications such as, for example, debugging, fault tolerance, and trace driven simulations. For example, logging and replaying allows a computer architect to perform detailed analysis of run-time information in an offline environment using trace simulations. Logging and replay can also be used to improve fault tolerance by enabling a virtual machine to recover from a system error by replaying execution from the last known save point. With regard to debugging, logging and replaying allows an analyst to identify what causes software bug to occur by recording the computer operation when the error is reproduced, and then stepping through the execution while reviewing the system state at each step to identify the cause.
Injecting recorded non-deterministic events at the correct time during playback of execution requires precisely counting instructions and branch occurrences to ensure fidelity of the playback with the original execution. Unfortunately, due to limitations of processor architecture, prior attempts at accurately counting execution branches has not been wholly successful. Accordingly, there is a need for a method for precisely counting branch instructions, e.g., for logging and replaying execution in a virtualized computing environment.